sequenceDiagram
    participant Scheduler as Scheduler
    participant Executor as Task Runner
    participant Verify as Verify Runner
    participant Audit as Audit Logger
    participant Stripe as Stripe API

    Scheduler->>Stripe: (if dynamic) POST create restricted key (mint)
    Stripe-->>Scheduler: return key id/secret/expires
    Scheduler->>Executor: dispatch compiled job (includes verify, materialization/handoff metadata, narrowed creds)
    Executor->>Executor: run main task command (spawn)
    Executor->>Executor: capture exit_code, stdout, stderr

    alt exit_code == 0 and verify present
        Executor->>Verify: runVerify(shell, timeout_seconds)
        Verify->>Verify: spawnSync('sh', ['-c', ...]) with timeout
        Verify-->>Executor: {passed, exit_code, stdout, stderr, timed_out, duration_ms}

        alt verify.passed or verify.on_failure == 'warn'
            Executor->>Audit: append verify result (warning if applicable)
        else
            Executor->>Executor: mark verify_failed, effectiveOk=false
            Executor->>Audit: emit failure audit (includes verify result)
            Executor->>Scheduler: propagate verify_failed error
        end
    else
        Executor->>Audit: log main execution result (no verify)
    end

    opt cleanup/handoff for dynamic keys
        Scheduler->>Stripe: DELETE restricted key (best-effort revoke)
    end

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

Follow-up review pass pushed in e0e1e46.

Addressed two execution-path regressions in this PR:

• task.verify now runs in the effective task cwd/env, so shell-local env vars and v0.2 materialized credentials are visible to the verify step.
• Dynamic Stripe sessions now revoke minted restricted keys from exec, including dry-run handoff preparation, and cleanup is awaited so warnings/results are deterministic.

Also wired task timeout into dynamic session resolution and documented the new workflow/task verify block in the field reference.

Local verification: npm test, npm run lint.

Superseded by the later follow-up comments on this PR. The previous body was malformed by shell escaping; the current review summary is in the newer owner comments and review notes.

One more follow-up commit is on the PR branch: e8a5808.

I found a second-order contract issue in the new verify path: the main task respected strict sandbox/network enforcement, but the post-success verify command was still shelling out directly. That meant verify could bypass the task contract on supported local sandbox runners.

This is now fixed by running verify through the same sandbox wrapper/profile when strict enforcement is active, with a regression test covering the darwin sandboxed path.

Validation rerun after the update: npm test, npm run lint.

Polish follow-up pushed in 160f856.

This pass does not change runtime behavior. It tightens the review surface around the current PR head:

• added a regression proving applyManifestToScheduler() keeps capability warnings in the structured result while still emitting the human-readable stderr advisory
• documented that task.verify runs after evidence generation and is recorded separately from the attested command result
• documented why identity.presentation.handoff is a hard compatibility gate while child_credential_policy="downscope" is only a warning when credential_handoff is unavailable
• cleaned up the malformed duplicate owner comment and resolved the remaining stale non-blocking review threads

Validation rerun on this head: npm test, npm run lint.

Post-merge assessment on PR #3 (160f8564d7e8409be3aec93c03185c06d0613260) plus current main:

• I did not find any remaining blocking issues in the merged PR changes themselves. The task.verify, dynamic Stripe key, and capability-warning work all looks coherent after the earlier follow-up docs/tests.
• I did find one current-main runtime gap adjacent to this PR: delegated exec handoff to openclaw-scheduler was enforcing hard capability errors but dropping soft capability warnings from the structured delegation receipt. That made exec inconsistent with apply --check-capabilities / apply for the same manifest shape.
• I also found that examples/ansible-ops.json had drifted out of schema (contract.audit: "full" instead of none | on-failure | always), which was breaking the repo’s all example manifests validate and compile test on clean main.

I pushed a small follow-up branch with both fixes:

• branch: followup/delegation-capability-warnings
• commit: a77630d
• compare: main...followup/delegation-capability-warnings

Validation on that branch:

• npm test: 592/592 passing
• npm run lint: passing

The new regression test covers delegated exec returning warnings / capability_warnings when the scheduler lacks runtime_identity_resolution, and the example repair restores the green full-suite baseline on main.